Reset error styling on the terms checkboxes (#491) - #1086

Fixes #491.

Affects the new-ride submission form at /addevent/. The edit form for an existing ride has no Terms panel, so it isn't impacted.

The problem

The error-styling reset and the error-styling application disagree about which containers they target.

Errors are applied to either container type:

var input = $('[name=' + fieldName + ']'),
    parent = input.closest('.form-group,.checkbox'),
...
parent.addClass('has-error')

But the reset at the top of the save handler only cleared one of them:

$('.form-group').removeClass('has-error');

The two terms checkboxes live in <div class="checkbox"> (edit.html:469, :476), not .form-group, so has-error was added to them and never removed — there is no other code path that clears it.

The neighbouring resets are selector-agnostic — $('[aria-invalid="true"]') and $('.help-block') — which is exactly why the reported symptom looks the way it does: the aria state and the help text both clear correctly, and only the red styling sticks.

The fix

One selector, bringing the reset in line with the containers the error path already uses:

-            $('.form-group').removeClass('has-error');
+            // must match the containers used when errors are applied below;
+            // the terms checkboxes live in '.checkbox', not '.form-group'.
+            $('.form-group, .checkbox').removeClass('has-error');

Two things beyond what the issue describes

1. The user got red with no explanation. Because $('.help-block').remove() is selector-agnostic, the message under the checkbox was being cleared while has-error stayed. So a corrected checkbox rendered red with no reason given, while the genuinely-broken fields above it were red with their "Organizer missing" / "Email missing" text. The one control the user had actually fixed was the one carrying unexplained red.

2. It also pinned the Terms panel open. The accordion logic keys off the same class:

errGroups = $('.has-error').closest('.panel-collapse');
okGroups = $('.panel-collapse').not(errGroups);
errGroups.collapse('show');
okGroups.collapse('hide');

The stale has-error kept the Terms accordion in errGroups, so it was held open on every resubmit even with nothing wrong in it. After this change the panel state is correct — Terms collapses once its checkboxes are ticked, and Contact Info stays open while it still has real errors.

Verification

Ran the issue's repro steps in Chrome against a local dev build, on the unmodified file and again on the patched one.

The 6 legitimate .form-group errors surviving in both columns is the control — corrected checkboxes reset without over-clearing errors that are still real.

Regression checks

• New ride, valid submission: saves normally, 0 remaining errors, redirects to /addevent/event-submitted. Backend created the event unpublished with the confirmation link logged, as expected.
• Editing an existing ride: cleared a required field and saved — 1 error shown; restored it and saved — 0 errors and "Your event has been updated!".
• npm test is 53/53, unchanged. (Backend-only suite, so it doesn't cover this file — noted for completeness rather than as evidence.)

To reproduce / review

1. npm run dev, then open http://localhost:3080/addevent/ (the new-ride form, not an edit link)
2. Pick any date; leave everything else blank; hit Save
3. Tick both terms checkboxes, leaving the other required fields blank
4. Hit Save again

Before: both checkbox labels stay red, with no message, and the Terms panel stays open.
After: they return to normal, the Terms panel collapses, and the remaining real errors are untouched.

Note for whoever picks this up next

The issue links to /site/themes/s2b_hugo_theme/static/js/cal/addevent.js#L186 and #L129. That file now lives under assets/js/cal/ (Hugo asset pipeline) and those line numbers no longer point at the relevant code.